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ABSTRACT: The Project Integration Architecture (PIA) implements a flexible , object-oriented , wrapping architecture 
which encapsulates all of the information associated with engineering applications. The architecture allows the progress 
of a project to be tracked and documented in its entirety By being a single , self-revealing architecture , the ability to 
develop single tools , for example a single graphical user interface , to span all applications is enabled. Additionally, by 
bringing all of the information sources and sinks of a project into a single architectural space , the ability to transport 
information between those applications becomes possible. Object-encapsulation further allows information to become in 
a sense self-aware , knowing things such as its own dimensionality and providing functionality appropriate to its kind. 


1 Introduction 

In the late 1980’s, the Integrated CFD and Experiments 
< ICE ) project [1,2] was carried out with the goal of provid- 
ing a single, graphical user interface (GUI) and data man- 
agement environment for a variety of CFD codes and re- 
luied experimental data. The intent of the ICE project was 
to ease* the difficulties of interacting with and intermingling 
these disparate information sources. The project was a suc- 
cess on a research basis; however, on review it was deemed 
inappropriate, due to various technical limitations, to ad- 
vance the effort beyond the successes achieved. 

A re-engineering of the project was initiated in 1996. The 
effort was first renamed the Portable, Redesigned Inte- 
grated CFD and Experments (PRICE) project and then, as 
the wide applicability of the concepts came to be appre- 
ciated, the Project Integration Architecture (PIA) project. 
Two key re-engineering decisions were made: the C lan- 
guage used by the ICE project would be abandoned in favor 
of the now-available C++ object-oriented extension to that 
language and the graphical user interface would be elimi- 
nated as a product element of the project. 

During the intervening years, work has proceeded and 
an operational demonstration of the PIA project has been 
achieved. 


1,1 Goals 

Put in simple terms, the basic goal of the PIA effort is to 
capture in its entirety the usage of any engineering applica- 
tion in a single, useful, well-defined form. This capturing 
is not limited to the simple output of the application itself, 
but further includes coordinating information and the engi- 
neer’s own insights into the meaning of the information. 

The nature of an ‘engineering application’ is, by project 
design, nebulus: it is considered to be any computer- 
realized ‘thing’ which provides or generates useful infor- 
mation about an engineering project. This may include 
CAD information, design code predictions, experimental 
data, engineering analysis and simulation, and more. 

By bringing all of the information of the engineering pro- 
cess into one architectural design, a number of advantages 
are expected to (and, it is believed, do) accrue. 

1 . The information about the information (referred to in 
some conceptions as the meta-data) is encapsulated 
with the information itself. 

2. A common tool set for the use of engineering applica- 
tions is possible. 
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3. Browsers and search engines may be implemented to 
peruse information in detail and convert it into infor- 
mation in general for end consumers. 

4. Object encapsulation allows information to become 
self-aware. For example, a measurement may know 
its dimensionality and provide its value appropriately 
converted to whatever system of measurement a re- 
quest is made in. 

5. By wrapping every application in a well-defined ar- 
chitecture, it is now possible to code the knowledge to 
acquire information automatically from other applica- 
tions. Such coded knowledge is based upon the kind 
of information desired, rather than upon the applica- 
tion generating that kind of information. 

6. Wrapped applications coded to obtain information 
based upon its kind may then be combined in a di- 
rected application graph to build, in effect, super- 
applications. Applications of differing fidelities and 
disciplines may be mixed together as appropriate to 
the project. 

7. The building of super-applications enables project- 
wide optimization, sensitivity analysis, and other such 
techniques to be conducted. 

1.2 Self Revelation 

Perhaps the key technology that enables the goals above is 
that of self revelation, the ability of a thing to reveal to oth- 
ers its own nature. Such a capacity can be implemented by 
many different techniques; however, it is a natural element 
of object-oriented technology. 

1.2.1 Self Revelation of Kind 

The revelation of kind identifies the essential character of 
the revealing entity. In the object-oriented implementation 
of PIA, this sets expectations as to the kind of information 
and functionality a particular object has. 

The revelation of kind is effected in two ways: an inter- 
rogative form and a declarative form. In the interrogative 
form, a predicate of kind is posed to the object and either 
affirmed or denied. In the declarative form, an inquiry is 
made of the object and a simple coded value is returned 
declaring the type of the object. 

Because of the derivational nature of object technology, 
both of these revelational forms support the concept of 
depth. That is, an object may be of a particular kind at 
some derivational depth but, because of further derivation, 


may not appear to be of that kind on its surface. The ex- 
amination of such layers of meaning is referred to (within 
this project at least) as ecdysiastical revelation. (From the 
Greek ekdysis , from ekdyein , to get out of, strip off.) 


1.2.2 Self Revelation of Content 

The revelation of content identifies the extent to which ex- 
pectations based upon the revelation of kind are, in fact, 
fulfilled. In such situations the expectation of content is 
nebulus by design and a well-defined method of further ex- 
position is defined. 

As an example of self revelation of content, consider the 
PacAppI application class which is to be discussed shortly. 
That class is defined has having a map of PacOp-derived 
operations objects; however, the map may be empty and, if 
it is not empty, it is unpredictable exactly which operations 
objects will, in fact, populate it. Thus, an expectation of 
content is defined, but the precise extent of content is left 
open with a defined method for further exploration. 


2 Application Architecture 

Building upon the concept of self revelation, an application 
architecture as depicted in Figure 2.1 has been devised. 

An application presented in the image of PIA begins with 
a central application object, labeled PacAppI in the upper 
center of the figure, which is the root structure from which 
all further components emanate. Four principal compo- 
nents are currently provided by the PacAppI object: 

1. A set of operations that the application is willing to 
perform, 

2. A mass of data which the application currently con- 
tains, 

3. A structure by which the contained data is identified, 
and 

4. An ecdysiastical sorting of the information-bearing 
objects in the application. 

The first three components are depicted in the figure in the 
upper left, the upper central to lower left diagonal, and the 
central right, respectively. The fourth component is not de- 
picted due to its structural complexity. Each of these com- 
ponents is taken up in its own subsection below. 
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Figure 2.1: PIA Application Architecture 


2.1 Application Components 

2.1.1 Parameter Configurations 

Parameter objects (the objects which hold application data 
of all forms) are held in configuration objects, labeled Pac- 
Cfg in the figure. A configuration is considered to be a 
distinct set of input and output data for the application. 
A configuration is further considered to parallel the vari- 
ous investigated designs of an engineering project so that 
synchronization of the engineering process is maintained 
across the entirety of the project. 

Configurations are arranged as an n-ary tree and inherit 
missing parameters from their ancestors, the most immedi- 
ate ancestor taking precedence for a given parameter. Thus, 
repetition of unchanging parameters is avoided. 

Parameters often exist in structural forms which may be re- 
peated within an application. To avoid the needless replica- 
tion of unchanged parameters simply to indicate parametric 
structure, individual parameters are identified by a fully- 
qualified name in which their structuralization is encoded. 

2.1.2 Parameter Identification 

The parameter identification structure (built of objects be- 
ginning with the label Pid in the figure) is the mechanism 
by which the structuralization of parameters is revealed. 
This parameter identification element of the application 
architecture is, again, arranged as an n-ary tree. The fully- 
qualified name of a parameter is developed by concatenat- 


ing the names of each of the tree elements leading to the 
final identification of that parameter. 


2,1.3 Operations 

Applications not only hold data, but usually operate on that 
data, turning inputs into outputs. To reveal these opera- 
tions, the architecture provides for a map of operational 
objects (labeled Op followed by a name in the upper left 
of Figure 2.1) sorted by operation name. 

Some operations may require specific interaction with 
the researcher. For this purpose, a GUT call-back class, 
PacGUI, is defined which provides a known set of inter- 
actions. Such an object must be supplied to each operation 
each time that operation is invoked. 


2.1.4 Object Sorting 

A fourth structure has been defined and implemented, but it 
is not shown in the figure due to its complexity. The struc- 
ture provides a ecdysiastically-exhaustive sorting of objects 
of the application by their derivational heritage. The need 
for this sorting arises because applications are permitted to 
specialize parameters beyond the level that is well known. 
By means of this sorting, applications seeking particular 
parameters by their well-known types may be quickly di- 
rected to those parameters, even though those parameters 
are customized at their derivational surface. 
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2.2 Operating Context 

The parameter identification and application operation ob- 
jects both operate in the context of a selected parameter 
configuration, a concept shown in the figure by the sweep- 
ing curves from those kinds of object to a single config- 
uration. These object kinds offer Is Visible and IsEnabled 
member functions, respectively, which indicate whether or 
not the functionality is active within the context of the se- 
lected parameter configuration. This feature allows, for ex- 
ample, the internal parameters of an optional analysis com- 
ponent to be made invisible when that component has been 
disabled in a particular configuration, even though those 
parameters might exist in, or be inherited by, that configu- 
ration. 


3 The Base Object 

Very' nearly all of the object classes involved in implement- 
ing the PI A application architecture described above are de- 
rived from a common base class, PacBObj. Among other 
things, this base class provides several key features: 

1 . The ability to be described, 

2. The ability to transmit declared events, and 

3. The ability to traverse upward through the application 
structure. 


3. 1 Descriptive Capabilities 

The ability to be described brings a good deal of useful 
function to the entirety of the architecture, A wide variety 
of descriptions, such as access controls, descriptive texts, 
dimensionality, and others, are implemented. Indeed, vir- 
tually any sort of descriptive element can be devised and 
added to the repertoire. Because not all objects will nec- 
essarily have descriptive elements and certainly not all ob- 
jects will have all descriptive elements, the descriptive sys- 
tem is one of minimal overhead. 

The only limitation of the descriptive system is that, within 
a descriptive set, at most one instance of any particular con- 
trolling descriptive type is permitted. This limitation is off- 
set by the fact that the descriptive system is implemented 
in a layered, hierarchial manner in parallel with the deriva- 
tional class hierarchy and that distinct descriptive sets may 
exist at each such level. Within this descriptive hierarchy, 
the top-most description (that is, the description of the most 
derived class level) of any kind is considered to be the pre- 
ferred description; however, the facilities exist to reveal the 
entirety of the descriptive hierarchy should it be desired. 


3.1.1 Engineering Logs 

A multi-line, descriptive text form is provided as the possi- 
ble basis of an engineering log facility. Here an indefinite, 
expandable number of text string elements in an ordered 
list can be associated with any PacBObj derived object. 


3.1.2 Change Histories 

A change history descriptive form is provided. It provides 
an implicitly time-stamped, ordered, multi-line descriptive 
form. This form is implicitly used by the PacPara (pa- 
rameter) base class to record parameter modifications as 
previous value texts. All currently implemented parame- 
ter classes utilize this capability in their corresponding Set- 
Value services. 


3.1.3 Access Controls 

An access control descriptive complex is implemented. 
Any PacBObj-derived object can attach access control de- 
scriptions throughout its descriptive hierarchy. This allows 
per-user read, write, execute, and delete controls to be ap- 
plied on an object-by-object basis. 


3.2 Declared Events 

A simple subscribe/publish event facility is provided by the 
PacBObj base class. This facility allows utilizing entities 
to attach one or more objects of PacEvent derivation to 
a PacBObj-derived object. The PacEvent base class de- 
fines a number of different event types but, as a base class, 
provides only a default response should the event be de- 
clared. The PacBObj base class implements correspond- 
ing event functions which, if invoked, will identify each 
attached event object and transmit the event declaration to 
it. 

Utilizing code is responsible for developing and attaching 
derived event class forms which do something meaningful 
should an event be declared. There is no artificial limita- 
tion on the number of event objects that may be attached 
to a particular PacBObj object, nor upon the number of 
PacBObj objects that may be attached to a particular event 
object. 


3.3 Upward Reference 

The basic direction of the application architecture is down 
from encompassing components to more specific compo- 
nents. In implementation, though, it is frequently necessary 
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to traverse in the opposite direction. This need is met by a 
pointer member and supporting code in the PacBObj class 
which references the next higher level element of the appli- 
cation structure. Implemented functionality allows traver- 
sal of this upward chain of reference until an object of a 
particular, specified kind is found. Thus, code can be in- 
sensitive to the exact placement of its presenting object in 
the architectural hierarchy. 


4 Parameters 

Information is encapsulated in a derivationally-rich set of 
parameter objects. The parameter derivational structure is 
based upon the PacBObj base class and, thus, all of the 
capabilities of that foundation are inherited. 


4.1 Dependent Parameters 

The parameter base class utilizes the directed graph capa- 
bilities inherited by it to implement a dependent parameter 
mechanism. Each successor (dependent) in such a graph is 
informed of any change in any of its predecessor (benefac- 
tor) parameters. This dependency mechanism is accounted 
for during the act of parameter replication, causing the 
replication of dependent parameters as needed. 


4.2 Infusion of Semantic Meaning into Parameter Ob- 
jects 

The self revelation of kind mechanism is used by the pa- 
rameter object hierarchy to infuse semantic meaning into 
parameters [3]. The first derivations of parameter ob- 
jects specialize parameters by their basic structural forms; 
scalar, vector, matrix, organizational, and the like. Further 
derivation then associates an atomic kind, long, double, 
Boolean, string, and the like, with these forms as appro- 
priate. 

A further specialization of double parameter kinds declares 
them to be dimensional in nature, that is being a measure- 
ment in a specified system of measurement. (The concepts 
of dimensionality are discussed in greater detail in [4].) 
From this point a great majority of engineering parameters 
may then be derived. 

By setting the dimensional elements to null values, di- 
mensional parameters are further specialized to be non- 
dimensional. By doing this, non-dimensional parameters 
may be freely intermixed with their dimensional counter- 
parts in dimensionally- sensitive operations. From this base, 
non-dimensional engineering parameters are then derived. 
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4.2.1 Related Parameters 

A related-parameter descriptive mechanism is utilized to 
associate other parametric information with semantically- 
defined parameter objects. For example a grid of informa- 
tion may identify a parameter giving the positions of its grid 
coordinates through the related parameter mechansism. 


5 Persistence 

Saving the state of an encapsulated application was a self- 
evident requirement. To achieve this, an object serialization 
capability was implemented. Object contents are written 
out to or read back from an archive file under the control of 
a Serialize function. An archive object keeps track of what 
objects have been serialized or de-serialized so that redun- 
dant references to an object are appropriately handled. 

The drawback of this serialization is also its strong point: a 
Serialize function must be manually coded for every class 
that might participate in such an operation. For the most 
part such coding amounts to mere tedium; however, it is 
in this coding that the groundwork for evolutionary change 
can be laid. If one takes the precaution of serializing an 
archive version number as the very first step of object se- 
rialization, then conditional code for the de-serialization of 
old object versions can be generated when object revisions 
are defined. By this means, old objects may be recovered 
even as object coding evolves. 


6 Information Propagation 

The infusion of semantic meaning into parameter objects 
through derived class specialization and self revelation 
forms the basis for the interapplication transfer of informa- 
tion by allowing one application to Took’ at parameters of 
another application and discern the semantic nature of the 
observed parameter objects. This basic technology enables 
a number of interapplication information transfer modes. 

The propagation of parametric information throughout an 
application graph is the first form of information transfer 
implemented by the PIA project [5], The goal is to arrange 
disparate applications into a cooperative graph whose oper- 
ation carries out all of the analyses relevant to an engineer- 
ing project as a whole. 

The graph of applications is currently constructed by op- 
erations of the testbed GUI. The first application created 
through the GUI is always made the initial node of an ap- 
plication graph. A right click on that application (or upon 
any application subsequently added to the graph) pops up a 


menu with a pick for adding a successor application to the 
right-clicked application. The standard select-application 
dialog is then executed and the application-graph member 
added. 

A basic conceptual view behind the arrangement of an ap- 
plication graph is that there always exists some source def- 
inition of a proposed configuration of the project which 
then feeds as input to various analyses of that configura- 
tion. Those analyses then produce results with two po- 
tential aspects: intermediate values which are of use for 
further forms of analysis and final answers contributing to- 
ward a judgement of the engineering merit of the design. 

Another aspect implicit in this view of information propa- 
gation throughout directed application graphs is that such 
applications operate in a mode in which a single operation 
(from an external viewpoint) reliably turns input informa- 
tion into output information, as opposed to a scenario in 
which the propagation act must be iteratively performed 
until parametric values, in some sense, reach a balance or 
converge. Note, though, that such an iterative propagation 
form is not precluded by the PIA architecture, but is only 
in opposition to the assumptions of the information propa- 
gation form first implemented for study. 

Information propagation as presently implemented also 
forces the synchronization of parameter configurations. By 
this, the concept of a project configuration is made more 
real and, it is expected, the problem of mismatched config- 
urations within a project analysis will be eliminated. 

The propagation implementation also recognizes that not 
all applications are entirely reliable in their operation. To 
deal with this, the support utilizes the event mechanism 
built into the PacBObj base class to allow inappropriate 
operations to alert supposedly corrective entities. There is, 
thus, the ability to apply corrective measures and re-attempt 
a particular operation in the overall propagation activity 
Failing such corrective actions, the information propaga- 
tion system will mark the affected parameter configurations 
as being defective and will prevent further propagative acts 
based upon those configurations. 

The process of information propagation as currently imple- 
mented proceeds in the following general manner. 

1 . The process is begun by delivering a propagation com- 
mand citing a parameter configuration to an applica- 
tion object which is, typically, the initial node of an 
application graph. The event is typically delivered 
from an external, organizing entity, for example a per- 
son controlling the overall process through an inter- 
acting GUI. 


2. The application object converts inputs to outputs after 
its manner. 

3. The application then passes the propagation operation 
on to each of its immediate successors in the graph. 
The configuration is passed on in this act. 

4. Each receiving application establishes or creates a cor- 
reponding configuration. 

5. Each receiving application then examines each of the 
parameter objects available in the source configuration 
and, based upon the semantic meanings revealed by 
those parameters, acquires such information as it may. 

Each receiving successor application is free to exam- 
ine the extended predecessor applications of its own 
propagating immediate predecessor application for in- 
put information. 

6. When each successor has received a propagation act 
from each of its own immediate predecessors, it then 
operates to convert its own inputs into outputs and 
then passes the propagation act on to its immediate 
successors. 


7. The propagation of information continues in this man- 
ner throughout the graph until terminal nodes of the 
graph are reached and return the propagation act back 
up the graphical chain to the originator of the act. U1 
timately, this rolls up to a single return of control to 
the original initiator of the propagation act, indicating 
that the operation is complete. 

It should be remembered in all of this that it is the technol- 
ogy of self-revelation exposing infused semantic meaning 
that makes the implementation of information propagation 
tenable. Applications wrappers need only be coded to look 
for the kinds of information they desire to acquire during 
propagation. It is not necessary to code for connection to 
a specific source application to obtain an expected kind of 
information, nor is it necessary to code for specific topo- 
logical arrangements of applications. 


7 Documentation 

Complete, class-by-class, member-by-member documenta- 
tion has been generated in Hyper-Text Markup Language 
(HTML) format and placed on a central server at the Glenn 
Research Center. The root URL for this documentation is 

http://www.lerc.nasa.gov/WWW/priceOOO/index.html 


NASA/TM — 2001-210750 


6 


PR I CE Application Selection 


<* CapriGuiAppI 


C HiuAppI 

C LapAppI 


iii^asu 


Cancel 


Figure 9.1: GUI Opening Application Query 


It must be strongly emphasized that these pages are the in- 
formal generation of the researcher involved and do not, in 
any way, shape, or form, represent an official statement of 
the Government of the United States. 


8 Experience 

To date, three applications have been wrapped in the C++ 
implementation of the PIA Application Architecture: a pre- 
sentation of experimental data from an inlet unstart ex- 
periment for the High Speed Research project (known as 
HIU), a presentation of flowpath geometry information 
from Computer Aided Design (CAD) sources accessed 
through the Computational Analysis Programming Inter- 
face (CAPRI) cross-vendor package [6], and an operational 
wrapping of the Large Perturbation Inlet (LAPIN) analysis 
code [7]. Propagation of geometry information from the 
CAPRI/CAD wrapper to the LAPIN wrapper is currently 
being demonstrated. 


9 Testbed GUI 

Although a GUI is not considered to be a product of the 
overall project, such a tool is nevertheless necessary for 
testing purposes. Indeed, a GUI is the most expedient way 
to see that the concepts described above do, in fact, work. 

The first demonstration of the architecture is shown in Fig- 
ure 9. 1 . This is a screen capture of the application selection 
dialog box implemented by the GUI. The dialog allows the 
user to select one of the available application types through 
a mutually-exclusive radio button interaction. 

The remarkable thing about the application selection dialog 
is that it is generated on-the-fly by the GUI, rather than by a 
static coding of the dialog. At the time of dialog initializa- 
tion, a scan is done of all PIA classes, isolating those that 
are derived from the type PacAppl. (The class PacAppl it- 
self is excluded from this set.) A radio button is generated 
for each such identified application class, drawing the name 


► G«r PacAppil 





-1W 

: Computational Analysis Programming Interf 
■3 Capri 
9 Volume! 

Jt Boundaries 
; BoundingBox 
Edges 
ii Faces 
+ Nodes 
Volume 

Root Configuration 
PacCfg 02E1Q76G 
B PacCfg 02DBD950 
: PacClg: 02DFBC60 
S Operations 

ChooseArchiveFiie 
ChooseCADFJe 
ir; Successor Applications 
LapAppCQ2£!14EO 


r,[iApp! Q2E1T4KI 


Lapin 

& BC 

+ BypassEleed 
3$ Conirl 
Geometry 
|¥; Heat 
Inject 
•+• Loss 
■4; Output 
Root Configuration 
PacCfg: D2E1076D 
a PacCfg: 02DBD950 
PacCfg :02DFBC60 
Operations 

; Create All Lapin Parameters 
■ Load Fortran N amelist 
Run Lapin n Batch Mode 
Validate Parameter Configuration 
Predecessor Applications 

Computational Analysis Piogrammirig Interface 
Successor Applications 



ijfpr Help, press FI 


Figure 9.2: Display of Two Independent Applications Con- 
nected in a Graph 


text from the supporting class information. Thus, the figure 
shows that, at the time this dialog was captured, three ap- 
plications were supported: the CAPRI cross-vendor CAD 
geometry (CapriGuiAppI) application, the HSR Inlet Un- 
start (HiuAppI) application, and the LAPIN (LapAppl) 
application. 

Figure 9.2 illustrates nearly all the rest of the features of the 
architecture as exercised by the testbed GUI. The window 
labeled PacAppllrl views a CAPRI application choosen 
from an application selection dialog in the course of GUI 
startup. The window labeled PacAppll:2 views a second 
application, in this case a LAPIN application, that has been 
created as a successor to the CAPRI application in the ap- 
plication graph. 

A window viewing an application lists from top to bottom 


1 . The parameter identification tree (which is only par- 
tially expanded in either window of the figure for rea- 
sons of space), 

2. The parameter configuration graph, 

3. The operation tree, 

4. The application graph predecessor list (except in the 
case of the PacAppll:! window which views the ini- 
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tial node of the graph which, by definition, has no pre- 
decessors), and 

5. The application graph successor list. 

Comparing the differences between the two windows, for 
example the different operations lists, shows the self- 
revealing nature of applications within the architecture. 
The PacAppllrl window lists the two CAPRI operations; 
the selection of a CAD file from which an internal CAPRI 
archive of information will be produced, and the selection 
of such an archive from which a geometry parameter set in 
the selected configuration will be produced. Meanwhile, 
the PacAppll:2 LAPIN window lists an entirely differ- 
ent set of operations; the creation of LAPIN parameters, 
the loading of LAPIN parameters from traditional Fortran 
namelist input, the running of LAPIN, and the validation of 
the parameter set as input to a potential LAPIN run. 

The two viewing windows also reveal the connection be- 
tween the two applications as participants in an application 
graph. The PacAppIl:! window views the initial node of 
the application graph, as witnessed by the absense of a Pre- 
decessor Applications element in its view. The Successor 
Applications list of that view show s the LAPIN application 
viewed by the PacAppll:2 window as its successor. The 
LAPIN application, in turn, fists the CAPRI application of 
the PacAppUrl window as its predecessor. 

The effect of information propagation throughout the appli- 
cation graph is also illustrated by Figure 9.2, The param- 
eter configuration graph of the CAPRI application viewed 
through the PacAppll:l window has been expanded be- 
yond its default single -patriarch form to include two child 
configurations and a grandchild configuration attached to 
the second child. By the act of information propagation 
citing the root parameter configuration of the CAPRI appli- 
cation (effected by first selecting the root parameter config- 
uration of that application and then double-clicking the ap- 
plication element of the viewing window), that parameter 
configuration graph is replicated in the successor LAPIN 
application. This is further confirmed by the fact that the 
default parameter configuration object names generated in 
the CAPRI application as the configuration graph was ex- 
panded (for example, PacCfg:02E 10760) are, in fact, repli- 
cated in the configuration graph of the LAPIN application. 
This is precisely as expected by the act of information prop- 
agation as a result of its effort to keep parameter configura- 
tions synchronized between cooperating applications. 

This illustration of information propagation is somewhat 
overextended in order to demonstrate features of the ar- 


chitecture that reach beyond current realities. In fact, no 
CAPRI/CAD data source with multiple configurations ex- 
isted at the time of this writing. Thus, the descendent con- 
figurations are, in fact, empty. They exist to demonstrate 
the configuration bookkeeping aspects of the architecture. 

Another aspect of this information propagation figure is 
also not fulfilled at the time of writing in that no actual 
information was transferred between applications as a re- 
sult of the act that produced the display. This is due to two 
factors. First, there were still bugs in the program which 
w'ere being tracked down and corrected at the time of writ- 
ing. Second, no sematically correct CAD file for the sample 
problem, the inlet flow' path of the Rocket Based Combined 
Cycle engine being developed at the Glenn Research Cen- 
ter, was available at the time of writing. It is believed and 
represented in good faith that both these difficulties will be 
overcome in the near future. 


10 Future Directions 

At this point, the road ahead for the PIA project seems rel- 
atively clear. The key technology of self-revelation and its 
ability to enable common tools, information propagation 
throughout an application graph, and the like can be con- 
sidered well demonstrated. Further work now' must center 
on two areas: making the application architecture practica- 
ble by moving it to a distributed object environment, and 
filling in the many semantic gaps of the parameter object 
set so as to have a fully populated set of information forms. 

Work has already begun on the migration to a distributed 
object environment based upon the Common Object Re- 
quest Broker Architecture (CORBA). At this point, all 
foundation classes have been migrated to this environment 
and operationally demonstrated. Work on application-level 
classes and concepts is now beginning. 


11 Summary 

An abstract, highly flexible, object-oriented application ar- 
chitecture has been defined. The architecture has been im- 
plemented in C++ and real applications have been wxapped 
according to that architecture. Dimensional parameter ob- 
jects wrapped in this architecture are self-aware of their di- 
mensionallity and automatically convert their values to a 
requested unit system. Applications wrapped in this ar- 
chitecture have been connected into directed application 
graphs and the automatic propagation of information from 
source application to consumer has been demonstrated. 
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